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 Nameservers for the Address and Routing Parameter Area ("arpa") Domain

Abstract

   This document describes revisions to operational practices to
   separate the function of the "arpa" top-level domain in the DNS from
   its historical operation alongside the DNS root zone.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Architecture Board (IAB)
   and represents information that the IAB has deemed valuable to
   provide for permanent record.  It represents the consensus of the
   Internet Architecture Board (IAB).  Documents approved for
   publication by the IAB are not candidates for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
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1.  Introduction

   The "arpa" top-level domain [RFC3172] is designated as an
   "infrastructure domain" to support techniques defined by Internet
   standards.  Zones under the "arpa" domain provide various mappings,
   such as IP addresses to domain names and E.164 numbers to URIs.  It
   also contains special-use names such as "home", which is a nonunique
   name used in residential networks.

   Historically, the "arpa" zone has been hosted on almost all of the
   root nameservers (NSs), and [RFC3172] envisages the "arpa" domain to
   be "sufficiently critical that the operational requirements for the
   root servers apply to the operational requirements of the "arpa"
   servers".  To date, this has been implemented by serving the "arpa"
   domain directly on a subset of the root server infrastructure.

   This bundling of root nameserver and "arpa" nameserver operations has
   entwined management of the zones' contents and their infrastructures.
   As a result, some proposals under consideration by the IETF involving
   the "arpa" zone have been discarded due to the risk of conflict with
   operations associated with managing the content of the root zone or
   administering the root nameservers.

   The separation described in this document resolves the operational
   impacts of synchronizing edits to the root zone and the "arpa" zone
   by eliminating the current dependency and allowing more tailored
   operations based on the unique requirements of each zone.

2.  Requirements for the "arpa" Zone

   The "arpa" domain continues to play a role in critical Internet
   operations, and this change does not propose weakening operational
   requirements described in [RFC3172] for the domain.  Future
   operational requirements for the "arpa" domain are encouraged to
   follow strong baseline requirements such as those documented in
   [RFC7720].

   Changes to the administration of the "arpa" zone do not alter the
   management practices of other zones delegated within the "arpa"
   namespace.  For example, "ip6.arpa" would continue to be managed in
   accordance with [RFC5855].

3.  Transition Process

   The process will dedicate new hostnames to the servers that are
   authoritative for the "arpa" zone, but it will initially serve the
   "arpa" zone from the same hosts.

   Once completed, subsequent transitional phases could include using
   new hosts to replace or augment the existing root nameserver hosts
   and separating the editing and distribution of the "arpa" zone from
   necessarily being connected to the root zone.  Any future management
   considerations regarding how such changes may be performed are beyond
   the scope of this document.

3.1.  Dedicated Nameserver Hostnames

   Consistent with the use of the "arpa" namespace itself to host
   nameservers for other delegations in the "arpa" zone [RFC5855], this
   document specifies a new namespace of "ns.arpa", with the nameserver
   set for the "arpa" zone to be initially labeled as follows:

      a.ns.arpa
      b.ns.arpa
      c.ns.arpa
      ...

   Dedicated hostnames eliminate a logical dependency that requires the
   coordinated editing of the nameservers for the "arpa" zone and the
   root zone.  This component of this transition does not require that
   the underlying hosts that provide "arpa" name service (that is, the
   root nameservers) be altered.  The "arpa" zone will initially map the
   new hostnames to the same IP addresses that already provide service
   under the respective hostnames within "root-servers.net".

   Because these nameservers are completely within the "arpa" zone, they
   will require glue records in the root zone.  This is consistent with
   current practice and requires no operational changes to the root
   zone.

3.2.  Separation of Infrastructure

   After initially migrating the "arpa" zone to use hostnames that are
   not shared with the root zone, the underlying name service is
   expected to evolve such that it no longer directly aligns with a
   subset of root nameserver instances.  With no shared infrastructure
   between the root nameservers and the "arpa" nameservers, future novel
   applications for the "arpa" zone may be possible.

   Any subsequent change to the parties providing name service for the
   zone is considered a normal management responsibility and would be
   performed in accordance with [RFC3172].

3.3.  Zone Administration

   Publication of the "arpa" zone file to the authoritative "arpa"
   nameservers is currently undertaken alongside the root zone
   maintenance functions.  Upon the separation of the "arpa"
   infrastructure from the root nameserver infrastructure, publication
   of the "arpa" zone no longer necessarily needs to be technically
   linked or interrelated to the root zone publication mechanisms.

3.4.  Conclusion of Process

   Full technical separation of operations of the "arpa" zone and root
   zone minimally requires the following to be satisfied:

   *  The "arpa" zone no longer shares any hostnames in its nameserver
      set with the root zone.

   *  The hosts that provide authoritative name service are not the same
      hosts as the root nameservers, do not share any IPv4 or IPv6
      addresses with the root servers, and are sufficiently provisioned
      separately such that any unique "arpa" zone requirements can be
      deployed without affecting how root zone service is provided.

   *  The editorial and publication process for the "arpa" zone removes
      any common dependencies with the root zone process so that the
      "arpa" zone can be managed, edited, and provisioned wholly
      independently of the root zone.

   Such separation is ultimately sought to allow for novel uses of the
   "arpa" zone without the risk of inadvertently impacting root zone and
   root server operations.  It is recognized that achieving this state
   requires a deliberative process involving significant coordination to
   ensure impacts are minimized.

4.  IANA Considerations

   IANA shall coordinate the creation of the "ns.arpa" namespace and
   populate it with address records that reflect the IP addresses of the
   contemporary root servers documented within "root-servers.net" as its
   initial state.  The namespace may be provisioned either directly
   within the "arpa" zone (as an empty nonterminal) or through
   establishing a dedicated "ns.arpa" zone, according to operational
   requirements.

   IANA will initially migrate the 12 NS records for the "arpa" zone to
   point to their respective new entries in the "ns.arpa" domain.

   When these actions are complete, the IAB and IANA will consult and
   coordinate with all relevant parties on activity to reduce or
   eliminate reliance upon the root zone and root server infrastructure
   serving the "arpa" zone.  Such changes will be performed in
   compliance with [RFC3172] and shall be conducted with all due care
   and deliberation to mitigate potential impacts on critical
   infrastructure.

5.  Security Considerations

   The security of the "arpa" zone is not necessarily impacted by any
   aspects of these changes.  Robust practices associated with
   administering the content of the zone (including signing the zone
   with DNSSEC) as well as its distribution will continue to be
   necessary.
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